Add support for type checking with mypy plugins #121
Conversation
There was a problem hiding this comment.
Thanks for the PR!
I don't quite understand what the new global env is for. Other than that, this PR looks great and does the right thing: we should continue to setup a) a venv for mypy itself, b) project specific venvs. And then use PYTHONPATH (or other) shenanigans so that mypy can import from the project specific venv. We should also add an assert that some version of mypy itself isn't in the project specific venv, otherwise things will get confusing.
|
Thanks for the review, I'm gonna try to move back to using project specific venvs, see if I can get it to work. The global env was added to have a python/pip binary to reach to when I removed the project specific venvs. I'll see if I can get a reasonable assert in there too, perhaps just something naive like looking for |
|
I've updated to align with your suggestions. Let me know if there's anything else I've missed or should update. Though I can't say I follow why each project needs its own environment. I was thinking it would be preferable to have a virtualenv for each mypy installation and then do a "distributed" install for each project ( |
|
Thanks again for the PR, sorry that I lost track of it! |
I'm not totally sure if this approach always works or if there's stuff that I'm missing, but it seems to work. I'll try to explain myself here.The change utilisespip's--target(docs) argument to point out where to install a project's additional dependencies, passed in viapip_cmd. This replaces the virtual env creation for each project, since that shouldn't be necessary (I think?).In addition to what's mentioned abovewe start setting thePYTHONPATHenv variable(docs), to point out an additional search path for module files, namely the site-packages directorywith the additional dependenciesinside the project's virtualenv.That should allow discovery of project dependencies while keeping the installed mypy versions independent and reusable.
Outdated
All this isn't included, but I was thinking that it should be possible to use
pip install --targetfor both mypy installations as well, instead of a virtual env. That leads to having 1 python/pip executable, 1 directory fornew_mypy, 1 directory forold_mypyand then all project dependency installations. Although I'm unsure what--python-executable=does and if it could be affected. I'm also not sure how to handle compiled mypy.Essentially what'll happen with the above changes is that we'll have a directory structure like e.g.
repo-dir/ ├── new_mypy │ └── bin │ └── mypy ├── old_mypy │ └── bin │ └── mypy ├── projects │ ├── A │ └── B └── python └── bin └── pythonWe run mypy with something corresponding to
Here's some example debug output: